In my design while i was checking out the numbers I found that fanout/design repair is using dlyb_1 as for ordinary buffer is the what's suppose to happen ?
These are being added by the repair_design command in the flow
Deepak
In my design while i was checking out the numbers I found that fanout/design repair is using dlyb_1 as for ordinary buffer is the what's suppose to happen ?
These are being added by the repair_design command in the flow
Unfortunately, OpenROAD does not currently differentiate between data and hold buffers during buffer selection: https://github.com/The-OpenROAD-Project/OpenROAD/issues/10622
While you can disable all delay buffers, this would also mean that they could not be used for hold repair.
6:29 a.m.
@RebelMike did a workaround for his design where he replaced all setup-repair dlyb with normal buffers iirc.
Description It would sometimes be useful to replace the cell for a given instance, e.g. to change buffer type or resize a cell to improve timing. This could be an ECO step similar to InsertECOBuffe...
TinyQV including analog peripherals for TT GF 0.3. Contribute to MichaelBell/ttgf0p3-tinyQV development by creating an account on GitHub.
1
Leo Moser (mole99)
Unfortunately, OpenROAD does not currently differentiate between data and hold buffers during buffer selection: https://github.com/The-OpenROAD-Project/OpenROAD/issues/10622
While you can disable all delay buffers, this would also mean that they could not be used for hold repair.
ohh ok I tried to disable the delay cells this but the hold timing got bad so
I will check the work around
Btw would it effect the tapeout if the dlyb buffers are used instead of normal buffer ?
Deepak
ohh ok I tried to disable the delay cells this but the hold timing got bad so
I will check the work around
Btw would it effect the tapeout if the dlyb buffers are used instead of normal buffer ?
Anyone here have full SOC designs and having issues with very long synthesis times? Our same design for fpga on vivado takes 15-30 minutes to synth, but on yosys we’re seeing 12+ hours despite enabling multi threading and other usual suspects. Is this a known issue?
I opened a PR with yosys to merge some optimizations and it was rejected because it was “AI assisted” and I must admit the attitude was very disappointing despite providing follow ups, asking questions, etc.
Yes we do leverage the keep_hierarchy. I’m aware of the LLM rules but frankly it felt like an aversion not a guardrail. But I’m not keen to focus this discussion on that, I’m trying to understand if our synth times are abnormal and if we need to investigate a problem
J-Lo
Yes we do leverage the keep_hierarchy. I’m aware of the LLM rules but frankly it felt like an aversion not a guardrail. But I’m not keen to focus this discussion on that, I’m trying to understand if our synth times are abnormal and if we need to investigate a problem
This is a summary from my team, and because I’m seeing openroad yes it might be PNR
synthesis/signoff runs were spending huge time in OpenROAD.RepairDesignPostGPL. The dominant cause was a massive high-fanout reset net: i_chip_core.rst_n had about 38,354 terminals, and OpenROAD was serially building buffer trees for it. LibreLane parallelism knobs do not help this step much.
J-Lo
This is a summary from my team, and because I’m seeing openroad yes it might be PNR
synthesis/signoff runs were spending huge time in OpenROAD.RepairDesignPostGPL. The dominant cause was a massive high-fanout reset net: i_chip_core.rst_n had about 38,354 terminals, and OpenROAD was serially building buffer trees for it. LibreLane parallelism knobs do not help this step much.
Place and route runtimes are highly dependent on routing areas. Placing macros too close together or too close to the edges can result in unroutable designs.
bailey
Place and route runtimes are highly dependent on routing areas. Placing macros too close together or too close to the edges can result in unroutable designs.
Thanks we do have an SRAM macro in there and I wonder if that’s what’s causing some of our issues. I will note it is routable and we get a GDS, it just takes an obscenely long time to create
J-Lo
Thanks we do have an SRAM macro in there and I wonder if that’s what’s causing some of our issues. I will note it is routable and we get a GDS, it just takes an obscenely long time to create
Waiting for a file transfer of the final report but in summary I think you’re on to something, probably to do with the SRAM macro:
Dense SRAM macro grid. The current report has 39 SRAM macros consuming 4.48365 mm²; total core payload is 8.23514 / 12.90200 mm², about 64% including macros. In macros_3v3.yaml, SRAM columns at x=1040 and x=1380 are only about 38.7 µm apart after subtracting the 301.3 µm SRAM width.
1
6:12 p.m.
I’m not sure how solvable this problem is with such a short time until tape out. I think it’s just a challenge posed by the small chip area and requirement to have an SRAM
1
1
1
1